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SIP Protokoil zur Modif ikation von Bearerverbindungen 

in der Vergangenheit haben sich zwei wesentliche Typen von 
Kommunikationsnetzen zur Obermittlung von Informationen her- 
ausgebildet: Paketorientierte (Daten-) Netze und leitungsori- 
entierte (Sprach-) Netze. Im Zuge der Konvergenz diaser bei- 
den Netztypen haben sich konvergente (Sprach-Daten-) Netze 
herausgebildet. Durch Zusammenschluss dieser unterschiedli- 
chen Netztypen entstehen hybrids Netze, in denen der Gegen- 
stand der vorliegenden Erfindung mit besonders schSnen Vor- 
texlen zum Einsatz kommt. 

Leitungsorientierte Netze - auch Sprachnetze oder Telephon- 
netze genannt - sind auf die Obermittlung von in der Fachwelt 
auch als Gesprach, Call oder Session bezeichneten kontinuier- 
ixch stremenden (Sprach-) Informationen ausgelegt. Die Ober- 
mxttlung der Informationen erfolgt hierbei Qblicherweise mit 
hoher Dienstgate und Sicherheit. Beispielsweise ist far Spra- 
che exne minimale - z.B. < 200 ms - Verz5gerung (Delay, ohne 
Schwankungen der Verz5gerungszeit (Delay-Jitter, wichtig, da • 
Sprache bex WTiedergabe im Empf angsgerSt einen kontinuierli> 
Chen informationsfluss erfordert. Ein Inf ormationsverlust 
kann deshalb nicht durch ein nochmaliges Obermitteln der 
nxcht Obermittelten Information ausgeglichen werden und ftihrt 
xm Empfangsgerat tiblicherweise zu akustisch wahrnehmbaren 
Stcirungen (z.B. Knacksen, Verzerrung, Echo, Stille, . In der 
Fachwelt wird die Obermittlung von Sprache verallgemeinert 
auch als Echtzeit-(Obermittlungs-,Dienst bzw. als ^Realtime- 
Service' bezeichnet. 



35 drSC^'ilr ""^^^^ " tze genannt - sind auf 

35 dxe (feermxttlung von in der Fachwelt auch als -Datenpaket- 

strome. oder 'FloW bezeichneten PaketstrSmen ausgelegt. 

Hxerbex muss tiblicherweise keine hohe Dienstgfite garantiert 
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werden. Ohne garantierte DienstgUte erfolgt die Obermittlung 
der Datenpaketstreme z,B. mit zeitlich schwankenden VerzS- 
gerungen, da die einzelnen Datenpakete der DatenpaketstrOme 
Oblicherweise in der Reihenfolge ihres Netzzugangs abermit- 
telt werden, d.h. die zeitlichen VerzOgerungen werden umso 
grSfier, je mehr Pakete von einem Datennetz zu tibermitteln 
sind. In der Fachwelt wird die Obermittlung von Daten deshalb 
auch als Obermittlungsdienst ohne Echtzeitbedingungen bzw. 
als 'Non-Realtime-Service' bezeichnet. 



Die Pakete unterscheiden sich tiblicherweise je nach Art des 
paketorientierten Netzes. Sie kOnnen beispielsweise als In- 
ternet, X.25 Oder Frame Relay Pakete, aber auch als ATM Zel- 
len ausgebildet sein. Sie werden zuweilen auch als Nachrich- 
15 ten bezeichnet, v. a. dann, wenn eine Nachricht in einem Paket 
Obermittelt wird. 

Ein bekanntes Datennetz ist das Internet. Dieses wird wegen 
des dort zum Einsatz kommenden Internet Protokolls IP zuwei- 
len auch IP Netz genannt, wobei dieser Begriff grundsStzlich 
weit zu verstehen ist und alle Netze umfasst, in denen das IP 
Protokoll eingesetzt wird. Das Internet ist als offenes 
(Weitverkehrs-) Datennetz mit offenen Schnittstellen zur 
Verbindung von (zumeist lokalen und regionalen) Datennetzen 
25 unterschiedlicher Hersteller konzipiert. Es stellt eine vom 
Hersteller unabhangige Transportplattform zur VerfOgung. 

Verbindungen sind Kommunikationsbeziehungen zwischen zumin- 
dest zwei Teilnehmern zum Zweck einer - zumeist gegenseiti- 

30 gen, d.h, bi-direktionalen - InformationsObermittlung. Der 
_ die Verbindung initiierende Teilnehmer wird Ublicherweise als 
•A-Teilnehmer' bezeichnet. Ein durch eine Verbindung mit 
einem A-Teilnehmer in Verbindung gesetzter Teilnehmer heiJit 
'B-Teilnehmer' . In einem verbindungslosen Netz reprasentieren 

35 Verbindungen zumindest die auf logisch abstrakter Ebene ein- 
deutige Beziehung zwischen A- und B-Teilnehmer, d.h. entspre- 
chend dieser Sichtweise stellen z.B. die verbindungslosen 



2003 P 12425 



3 



Flows im Internet logisch abstrahierte Verbindungen dar (z.B. 
A-Teilnehmer = Browser und B-Teilnehmer - Web Server) . In 
einem verbindungsorientierten Netz reprSsentieren Verbindun- 
gen zudem auf physikalischer Ebene eindeutige Wege durch das 
Netz, entlang denen die Informationen ttbermittelt werden. 

im Zuge der Konvergenz von Sprach- und Datennetzen werden 
SprachObermittlungsdienste und zunehmend auch breitbandigere 
Dienste wie z.B. Obermittlung von Bewegtbildinformationen 
ebenfalls in paketorientierten Netzen realisiert, d.h. die 
Obermittlung der bisher Ublicherweise leitungsorientiert 
abermittelten Echtzeitdienste erfolgt in einem konvergenten 
Netz - auch Sprach-Daten-Netz genannt - paketorientiert, d.h. 
in Paketstr6men. Diese werden auch EchtzeitpaketstrOme ge- 
nannt. Die Obermittlung von Sprachinformationen Uber ein 
paketorientiertes IP Netz wird dabei auch mit -VoIP' (Voice 
over IP) gekennzeichnet. 

In den internationalen Standardisierungsgremien IETF (Inter- 
net Engineering Task Force) und ITU (International Telecommu- 
nications Union) mehrere verteilte Architekturen far Sprach- 
Daten-Netze beschrieben. Allen ist gemeinsam, dass die Call 
control Ebene und die Resource Control Ebene funktional deut- 
lich voneinander getrennt sind und meist sogar auf unter- 
schiedlichen Hardware Plattformen realisiert werden. 

Die Call Control Ebene umfasst dabei zumindest einen (optio- 
nalen) Call Controller, dem u,a. folgende Funktionen zugeord- 

net sind: 

- Address Translation: Umsetzung von E.164 Telephonnummern 
und anderen Alias Adressen (z.B. Rechnernamen) auf Trans- 
portadressen (z.B. Internetadressen) . 

- Admission Control (optional) : Grundsatzliche ZulMssig- 
keitsprUfung, ob und in welchem Umfang (z.B. VoIP fahige) 
Einrichtungen das Kommunikationsnetz nutzen dUrfen 

- Bandwidth Control (optional) ; Verwaltung von Obermitt- 
lungskapazitaten. 
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- Zone Management: Registrierung von (z.B. VoIP fahigen) 
Einrichtungen und Bereitstellung obiger Funktionen fOr al- 
le beim Call Controller registrierten Einrichtungen. 

Optional kSnnen einem Call Controller zudem folgende Funktio- 
nen fallweise zugeordnet werden: 

- Call Control Signaling: Alle Signalisierungsnachrichten 
werden von zumindest einem Call Controller vermittelt, 
d.h. alle Einrichtungen schicken und erhalten Signalisie- 
rungsnachrichten nur ttber den Call Controller. Ein direk- 
ter Austausch von Signalisierungsnachrichten zwischen den 
Einrichtungen ist untersagt. 

- Call Authorization: ZuiassigkeitsprUfung fflr eingehende 
und ausgehende Calls. 

- Bandwidth Management: Steuerung der zulassigen Anzahl von 
Einrichtungen, die gleichzeitig das Kommunikationsnetz 
nutzen dttrfen. 

- Call Management: Verwaltung einer Liste bestehender Ge- 
sprache, um z.B. ein Besetzzeichen erzeugen zu kannen, 
falls dies von der Einrichtung selbst nicht erzeugt werden 
kann. 

- Alias Address Modification: Rackgabe einer modif izierten 
Alias Adresse, bspw. mit einer H. 225.0 Nachricht ACF (Ad- 
mission Confirmation) . Diese Adresse muss der Endpunkt bei 
Verbindungsaufbau verwenden. 

- Dialed Digit Translation: Obersetzung der gewahlten Zif- 
fem in eine e:.164 Telephonnuramer oder eine Nummer aus ei- 
nem privaten Nummerierungsschema. 

Beispiele ftlr Call Controller stellen der von der ITO in der 
H.323 Standard Familie vorgeschlagene 'Gatekeeper' Oder der 
von der IETF vorgeschlagene 'SIP Proxy' dar. Wird ein groBe- 
res Kommunikationsnetz in mehrere Doraanen - auch 'Zonen' 
genannt - gegliedert, kann in jeder DomSne ein separater Call 
Controller vorgesehen werden. Eine Domane kann auch ohne 
einen Call Controller betrieben werden. Sind mehrere Call 
Controller in einer DomSne vorgesehen, soil nur ein einziger 
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von diesen aktlviert seln. Ei„ Call Controller 1st aus loai- 
scher Sicht getrennt von den Einrlchtungen zu sehen. Physlka- 

llTl2r " ^T""" -P-aten call Controller 

E.nrxchtung real.siert sein, sondern kann auoh in Jedem End- 
punkt elner Verbindung (beispielsweise ausgebildet als H.323 
Oder SIP Endpunkt, Endgerat, Media Gateway, Multipoint 
control Bnlt, Oder auch einer primer zur progranungesteuerten 
Datenverarbeltung ausgebildeten Einrichtung (bei.pielsweise- 
Rechner. PC Server, vorgesehen werden. Auch eine physlka! 
lisoh verteilte Realisierung 1st ,«>glich. 

11 tTT^'^"" ^" -^'^-y controller, 

de. Ublxoher^else die optionalen Punktionen Call Control 

ITT"', "--agement zugeordnet warden. Weiterhin 

iat die Zuordnung einer Punktion Signaling Conversion zur 
Om^setzung untersohledlicher (Signallslerung-, ProtoJcoXle 

'."^^ unterschiedllohen 
T.Z^rT^'l^lrZ^'"^'^'' -^^^ -a^engescKlossen sind, 

Contr:ii:rV°""' •^'^^"^ ^->^"<'-' «esourc, 

controller, dem u.a. folgende Funlctlonen zugeordnet sind: 

" durrp'^.T!"'' "—"9 des de™ Ko«„„ikationsnetz 
Kon^^of? H r ^"9-"'^'^^- VerHehrsvolu^ens. z.B. durch 
Kontrolle der Obermlttlungskapazitat einzelner Paketstra- 

" PaketLrrr"" '°P"°'«'^> = einen priorisierten 

Paketstrom Resourcen Im Kommunikatlonsnetz far dessen 0- 
bermxttlung reservleren. 

Priority Management (optional, : Priorttatskennzeichen in 
den Paketen entspreohend der Prioritat ihrer PaketstrOme 
setzen kontrollieren und gegebenenfalla korrigieren, 
falls die Pakete bereits Mit Prlorltaten gekennzeichnet 

^Dpf'T"' ^^^^ 'Policy Decision Point 

(PDP, bezexchnet. Er ist beispielsweise innerhalb von sog. 
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Edge Routern - auch Edge Device, Zugangsknoten oder bei Zu- 
ordnung zu einem Internet Service Provider (ISP) auch Provi- 
der Edge Router (PER) genannt - realisiert. Diese Edge Router 
kOnnen auch als Media Gateway zu anderen Netzen ausgebildet 
sein, mit denen die Sprach-Daten-Netze verbunden warden. 
Diese Media Gateway sind dann sowohl mit einem Sprach-Daten- 
Netz als mit den anderen Netzen verbunden und dienen intern 
der Urasetzung zwlschen den unterschiedlichen (Obermittlungs-) 
Protokollen der verschiedenen Netze. Der Resource Controller 
kann auch nur als Proxy ausgebildet sein und Resource Cont- 
roller relevante Informationen an eine separate Einrichtung 
weiterleiten, auf der die relevanten Informationen entspre- 
chend einer Funktion des Resource Controllers bearbeitet 
werden . 



Zur Koordination der beiden Ebenen wird Oblicherweise eine 
Mehrzahl von Nachrichten versendet, die lediglich zur Abstim- 
mung der beteiligten Komponenten untereinander, jedoch nicht 
zur Obermittlung der "eigentlichen" Informationen zwischen 
den Endgeraten dienen. Diese mit den Nachrichten tibermittel- 
ten Informationen werden Ublicherweise als Signalisierungsin- 
formationen, Signalisierungsdaten bzw. schlicht als Signali- 
sierung bezeichnet. Der Begriff ist dabei weit zu verstehen. 
So sind z.B. neben den Signalisierungsnachrichten auch die 
25 Nachrichten gemSB dem RAS Protokoll, die Nachrichten gemSB 
dem ITU-Standard H.245 zur Steuerung von NutzkanSlen beste- 
hender GesprSche sowie alle weiteren ahnlich ausgebildeten 
Nachrichten umfasst. Das Signalisierungsprotokoll far den 
Verbindungsaufbau (Call Setup) und -abbau (Call Release) nach 
der ITU ist 2.B. im Standard H. 225.0 beschrieben, das nach 
der IETF im RFC2543 ("SIP: Session Initiation Protocol") bzw. 
dessen Oberarbeitungen RFC2543bis0x oder RFC3261. Die "ei- 
gentlichen Informationen" werden zur Unterscheidung von der 
Signalisierung auch Nutzinf ormationen, Payload, Medieninfor- 
35 mationen, Mediendaten oder schlicht Medien genannt. Kommuni- 
kationsbeziehungen, die zur Obermittlung der Signalisierung 
dienen, werden im weiteren auch als Signalisierungsverbindun- 
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gen bezeichnet. Die zur Obermittlung der Nutzinformationen 
exngesetzten Kommunikationsbeziehungen werden z.B. Sprechver- 
bxndung, Nutzkanalverbindung oder - vereinfacht - Nutzkanal 
Bearerchannel oder schlicht Bearer genannt. In diesem Zusam- 
menhang versteht man unter out-of-band bzw. outband die Ober- 
mxttlung von Informationen auf einem anderen Weg / Medium als 
den im Kommunikationsnetz zur Obermittlung von Signalisie- 
rungs- und Nutzinformationen vorgesehenen. Insbesondere ist 
hiervon eine lokale Konfiguration von Einrichtungen vor Ort 
umfasst, die z.B. mit einer lokalen Steuereinrichtung vorge- 
nommen wird. DemgegenOber werden bei in-band Informationen 
auf dem gleichen Weg / Medium, ggf . logisch getrennt von den 
betrachteten Signalisierungs- und Nutzinformationen, iibermit- 

Das prinzipielle Zusammenwirken der beiden Ebenen sei am 
Bexspiel eines Call Setup zwischen zwei als Teilnehmerendge- 
r^te ausgebildeten VoIP Einrichtungen eriautert. Dabei wird 
zunachst von einem homogenen Sprach-Daten-Netz ausgegangen. 

innerhalb oder teilweise auch zeitlich vor dem eigentlichen 
call setup laufen bei Einwahl eines EndgerSts in das IP-Netz 
(z.B. txber einen Internet Service Provider) die Schritte 
Authentisierung, Autorisierung und (Start des) Accounting ab. 
Diese sogenannte 'AAA' Funktionalitat wird tlblicherweise 
durch den Zugriff auf eine Subscriber-Datenbank, in der alle 
Nutzer mit ihren Kennungen, PasswSrtem, Rechten, etc. ge- 
speichert sind, realisiert. Dieser Zugriff ist langsam und 
vergleichsweise komplex. In den heutigen "Best Effort" IP 
Netzen findet dieser AAA Vorgang normalerweise einmal wShrend 
des Exnwahlens des Nutzers statt. Eine weitere Authentisie- 
rung erfolgt bei Einsatz eines Call Controllers, wenn sich 
das Endgerat beim Call Controller des Internet Service Provi- 
ders registriert. Nach dem ITU-Standard H.323 wird diese 
Authentisierung bzw. Registrierung eines Endgerats beim zuge- 
ordneten Gatekeeper gemSfl dem RAS (Registration, Admission; 
Status) Protokoll durchgefUhrt, das im ITU-Standard H.225.0 
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beschrleben ist. 

Der eigentliche Call Setup beginnt tiblicherweise damit, dass 
in einem ersten Schritt die Endgerate der Teilnehmer ihre 
Fahigkeiten (z,B, Liste der unterstUtzten CODEC) austauschen, 
um die benatigten Ressourcen (z.B. Bandbreite) und die gefor- 
derte QoS (z.B. Delay, Jitter) zu bestimmen. Die Endger^te 
sind bei Sprachtelephonie z.B. als IP Telephone oder VoIP 
Client Software ausgebildet, bei Online-Video k5nnte eines 
der Endger^te ein Content- bzw. Application-Server sein, z.B. 
im Netz des Internet Service Providers (ISP) . 

Der Austausch der Signalisierungsnachrichten erfolgt entweder 
direkt zwischen den Endgeraten oder unter Vermittlung eines 
Call Controllers. Hierbei ist bei jedem Call fur jedes Endge- 
rat und fiir jede Obertragungsrichtung individuell festgelegt, 
welche Variante zum Einsatz koimnt. Die erste Variante wird in 
der H.323 Terminologie auch als 'Direct Endpoint Call Signal- 
ing' und die zweite als 'Gatekeeper Routed Call Signaling' 
bezeichnet. Bei Direct Endpoint Call Signaling kOnnen an 
einen Call Controller ggf • Kopien ausgewShlter Signalisie- 
rungsnachrichten ubermittelt werden,. so dass ein Call Cont- 
roller auch bei dieser Variante haufig Kenntnis von den zwi- 
schen den Endgeraten abgestiinmten Ressourcen- und QoS- 
Anforderungen hat. Diese Anforderungen werden jedoch von ihm 
selbst nicht aktiv beeinflusst oder verifiziert. 

Alternativ kann auch das SIP Protokoll zum Einsatz kornmen, 
und zwar sowohl far IP Gerate als auch zwischen Media Gateway 
Controllern. Im zweiten Fall wird das SIP Protokoll mit 
SIP_T (SIP for Telephones) bezeichnet^ das im Standard 
RFC3372 beschrieben ist. Wenn ein Call mit Hilfe des SIP 
Protokolls aufgebaut wird/ so wird zwischen den beiden Seiten 
der Verbindung ablicherweise eine Beschreibung des Bearers 
ausgetauscht . Dazu wird das Session Description Protocol 
(SDP) nach dem Standard RFC2327 eingesetzt. Dieser Einsatz 
ist u.a. im Standard RFC3264: "i\n Offer/Answer Model with the 
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Session Description Protocol (SDP) " beschrieben. Wichtig sind 
dabei vor allem folgende Bearer Daten: 

- IP Adresse der Bearer Connection 

- RTP/UDP Port der Bearer Connection (je nachdem, ob eine 
Sprach- Oder Datentibertragung vorliegt) 

- Codec (s), die far die Sprach bzw. DatenObertragung bentttzt 
werden (kdnnen) 

- Streainmode der Bearer Connection 

In einem zweiten, optionalen Schritt kann die derart abge- 
stimmte Ressourcen- und QoS-Anforderung direkt von den Endge- 
raten der Teilnehmer an ihren zugeordneten Resource Control- 
ler tibermittelt werden. Nach Priifung der Ressourcen- und QoS- 
Anforderung wird von dem Resource Controller eine Bestatigung 
(Oder Ablehnung) an das Endgerat zurtickgeschickt. 

In einem dritten, ebenfalls optionalen Schritt wird im Edge 
Router und gegebenenfalls weiteren Routem im Netz eine Poli- 
cy aktiviert, mit der diese Router prafen und gewahrleisten, 
dass der vom Endgerat verursachte Verkehr innerhalb der Gren- 
zen liegt, die in der Anforderung spezifiziert wurden. Ein 
Beispiel far einen derartigen Reservierungsmechanismus ist 
RSVP (resource Reservation Protocol) . 

Zusammenfassend kann der Function Split zwischen den beiden 
Ebenen so beschrieben werden, dass der Resource Control Ebene 
lediglich die Funktionen zugeordnet sind, die zur Obermitt- 
lung von Nutzinformationen erforderlich sind, wahrend von der 
Call Control Ebene die Intelligenz zur Steuerung der Resource 
control Ebene umfasst ist. Mit anderen Worten: Die Einrich- 
tungen der Resource Control Ebene besitzen mOglichst keine 
Netzsteuerungsintelligenz und k6nnen in der Folge wirtschaft- 
ixch besonders vorteilhaft auf separaten Hardware Plattformen 
realisiert werden. Dies ist wegen der im Vergleich zu Call 
Control Ebene hSheren Installationszahlen in dieser Ebene ein 
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besonders sch5ner Vorteil. 

Sowohl in konvergenten Sprach-Daten-Netzen als auch in hybri- 
den Netzen, die z,B, durch einen Zusanimenschluss eines kon- 
5 vergenten Sprach-Daten-Netzes mit einem konventionellen lei- 
tungsorientierten Sprachnetz gebildet werden, entstehen bei 
der Obermittlung von Infoinnationen - insbesondere der in 
EchtzeitpaketstrOmen - neue technische Problemstellungen 
aufgrund der neuen bzw. unterschiedlichen Technologien, die 
10 in den jeweiligen Netztypen zum Einsatz komnien. 

Es ist Aufgabe der Erfindung, zumindest eines dieser Probleme 
zu erkennen und durch Angabe von zumindest einer Losung den 
Stand der Technik zu bereichern, 

15 

Die Erfindung stellt sich die Frage^ ob nach dem Aufbau eines 
Calls aber das SIP Protokoll weiterhin alle Features genutzt 
werden konnen, die derzeit aus der Telefonie bekannt sind. 
Bei vielen dieser Features sind dabei Modif ikationen des IP • 
20 Bearers notwendig^ z.B.: 

" Umschaltung der Sprachverbindung auf Datenubertragung fQr 
Fax- und Modem-Anwendungen 

- Bearer Redirection (z.B. ftir die Umleitung der Verbindung 
25 auf ein Announcement) 

- Neuaushandlung des Sprach-/Datencodecs wahrend des Calls 
(Mid Call Codec Negotiation) 

- Call Hold und Call Retrieve 

30 Alle oben genannten Features haben einen neuen Austausch der 
Bearer Beschreibung in Form einer SDP Session zur Folge, die 
in einer SIP/SIP_T:Re-INVITE Meldung bzw, der zugehorigen 
SIP/SIP_T Response transportiert wird. Dabei wird die Ursache 
fOr die Bearer Modifikation weder im SIP Protokoll noch in 

35 der SDP Session explizit ubertragen, sondern muss auf der 

empfangenden Seite aus den SDP Daten, mit denen lediglich die 
Bearer Modifikation angezeigt wird, regeneriert werden. Diese 
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Regenerierung ist aber nicht immer eindeutig mdglich. Bei- 
spielsweise kann es in folgenden Fallen Probleme geben: 

- Wird der Codec einer Sprachverbindung geSndert, kann dies 
ein Codec Switchover fttr Fax/Modem, ein Switchover auf ei 
nen neuen Sprachcodec, oder aber auch eine Neuaushandlung 
des Sprachcodecs wahrend des Calls (Mid Call Codec Negoti 
ation) sein. 

- Werden mehrere Features kombiniert, ist es zuweilen nicht 
mehr maglich, anhand der neu empfangenen SDP Session zu 
ermitteln, welche Features kombiniert wurden. Eine SDP 
Session ftlr Bearer Redirect sieht beispielsweise genauso 
aus wie eine SDP Session, die far gleichzeitiges Call 
Retrieve und Bearer Redirect geschickt wird. 

Ohne eindeutige Regenerierung der Ursache kann auf der emp- 
fangenden Seite jedoch keine aussagekrSftige Mitteilung ge- 
troffen werden (z.B. am Display eines Telephons oder auf der 
Bedienoberfiache eines Software Telephon Clients), welches 
Feature gerade von der sendenden Seite aktiviert worden ist. 

Eine LOsung far diese der Erfindung zugrunde liegende Prob- 
lemsituation ist in den Patentansprachen angegeben. 

Mit dieser LOsung sind eine Vielzahl von Vorteilen verbunden 

- Durch Obermittlung der Ursache der Bearer Modifikation 
wird eine uneingeschrankte Nutzung verschiedenster Tele- 
phonie Leistungsmerkitiale ermttglicht. 

- Das bisherige, zum Teil sehr aufwSndige, deduktive Brmit- 
teln der Ursache der Bearer Modifikation anhand der Ober- 
mittelten Bearer Modifikation entfailt. 

- Durch die (eindeutige) Angabe der Ursache (n) der Bearer 
Modifikation kOnnen die von der sendenden Seite aktivier- 
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ten Features auch dann bestiinmt und angezeigt werden, wenn 
diese nicht deduktiv aus der Bearer Modifikation regene- 
rlerbar sind. 

5 Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben 
sich aus den unter- oder nebengeordneten AnsprUchen. 

Das Interworking zwischen den Protokollen SIP / SIP_T und den 
Protokollen BICC CS2 / ISOP+ (siehe ITU-T Recommendation 

10 Q. 1902.x, Bearer Independent Call Control Protocol CS2) wird 
grundlegend vereinfacht, wenn das Protokollelement als action 
Parameter mit folgenden Werten ausgebildet ist: connect- 
backward, connect- forward, connect-forward-no-notif ication, 
connect-forward-plus-notification, connect-forward-no notifi- 

15 cation-plus-selected codec, connect forward-plus- 
notification-plus-selected codec, connected, switched, se- 
lected-codec, modify-codec, successful-codec-modification, 
codec-modification-failure, mid-call-codec-negotiation, mod- 
ify-to-selected-codec-information, mid-call-codec- 

20 negotiation-failure, redirect -backwards-request, redirect- 

forwards -request, redirect-bearer-release-request, redirect- 
bearer-release-proceed, redirect-bearer-release-complete, 
redirect-cut-through-request, redirect-bearer-connected- 
indication, redirect-failure, remote-hold, remote-hold-ack, 

25 remote-retrieval, remote-retrieval-ack, weil der action Para- 
meter so problemlos in die BICC CS2 / ISUP+ Informationsele- 
mente "Action Indicator" und "Bearer Redirection Indicators" 
umgesetzt werden kann. 

30 Die Erfindung wird im folgenden anhand von weiteren Ausfiih- 
rungsbeispielen, die auch in den Figuren dargestellt sind, 
erlautert. Dabei zeigt: 

Figur 1 eine Anordnung zur DurchfOhrung des erf indungsgema- 
3^ fi®^ Verfahrens mit einem hybriden Kommuni kat ions- 

net z, bestehend aus einem paketorientierten, integ- 
rierten Sprach-Daten-Netz und einem leitungsorien- 
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tierten Sprachnetz, die durch zwischengeschaltete 
Media Gateways und Media Gateway Controller verbun- 
den sind, sowie zwei Endpunkten einer Informations- 
tibermittlung 

Figur 2 ein Ablaufdiagrairan, in dem eine Ausfuhrung der 
Erfindung exemplarisch aufgezeigt ist 

In Figur 1 ist eine beispielhafte Anordnung zur DurchfUhrung 
des erfindungsgemafien Verfahrens dargestellt. Sie umfasst ein 
leitungsorientiertes Netz PSTN und ein Kommunikationsnetz IN, 
das vorzugsweise als integriertes Sprach-Da ten-Net z SDN aus- 
gebildet ist. Die beiden Netze PSTN, IN sind zu einem hybri- 
den Netz zusammengeschlossen. Das Netz IN ist vorzugsweise 
als ein IP Netz (z.B. das Internet) ausgebildet und umfasst 
als Call Controller einen SIP Proxy SP. 

Der Zusammenschluss des leitungsorientierten Bearers TDM rait 
dem paketorientierten Bearer RTP/RTCP wird durch ein zwi- 
schengeschaltetes Media Gateways MG zur Konvertierung zwi- 
schen unterschiedlichen, netzspezifischen Nutzkanaltechnolo- 
gien RTP/RTCP (Real Time [Control] Protocol) und TDM (Time 
Devision Multiplex) , der Zusammenschluss der Signalisierung 
SS7 des Netzes PSTN mit der Signalisierung SIP des Netzes IN 
durch zwischengeschaltete Media Gateway Controller MGC^., zur 
Konvertierung zwischen unterschiedlichen netzspezifischen 
SignalisierungsprotokoUen SIP (Session Initiation Protocol) 
bewirkt. Dabei kommt zwischen den Controllem MGCi und MGC3 
ein Protokoll BICC CS2 / ISOP+ und zwischen den Controllem 
MGC3 und MGC2 ein Protokoll SIP_T (SIP for Telephones) zum 
Einsatz. 

Das Gateway MG wird von dem ihm zugeordneten Controller MGCx 
durch ein - vorzugsweise international genormtes - Protokoll, 
z.B. MGCP (Media Gateway Control Protocol) oder H.248 gesteu- 
ert. Es ist Oblicherweise als separate Einheit realisiert, 
die auf einer anderen physikalischen Einrichtung / Hardware 
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Plattform zum Ablauf kommt als die Controller MGC. 

An das Netz PSTN* ist ein Teilnehmer A mit Hilfe eines her- 
kommlichen Telephons T, an das Netz IN ein Teilnehmer B mit 
der eines SIP fahigen Telephons - z.B. eines in Software 
realisierten SIP Clients SC - angeschlossen, zwischen denen 
als Bearer eine end-to-end Nutzverbindung TDM, RTP/RTCP ein- 
gerichtet ist. 



In Figur 2 ist die Abfolge von SIP Nachrichten {l)-(4) zxjm 
Aufbau eines Bearers zwischen zwei SIP Clients A, B und von 
Nachrichten (5) -(17) zur Modif ikation des Bearers durch Wei- 
terleitung des Call von dem SIP Client B zu einem SIP Client 
C dargestellt, in der die Nachrichten (5), <6), (12), (13), 
15 (15) und (16) gemftB einem erfindungsgemafien SIP Protokoll ausge- 
bildet sind. 



Es sei betont, dass die derart aufgezeigten Ausfiihrungen der 
Erfindung trotz ihre teiiweise sehr detailgetreuen Darstel- 
lung von konkreten Netzszenarien lediglich beispielhafter 
Natur und nicht einschrankend zu verstehen sind. Dem Fachmann 
ist klar, dass die Erfindung bei alien denkbaren Netzkonfigu- 
rationen, insbesondere anderen Interworking Szenarien sowie 
weiteren paketorientierten Netzen zum Einsatz kommen kann wie 
25 z.B. Intranet, Extranet, einem lokalen Netz (Local Area Net- 
work - LAN) Oder einem, z.B. als Virtuelles Privates Netz 
(VPN) ausgebildeten firmenlnternen Netz (Corporate Network) . 

In dem AusfOhrungsbeispiel nach Figur 1 werden das SIP Proto- 
koll soMie sein Derivat SIP_T in einem komplexen, hybrlden 
Netzszenario eingesetzt, bei dem die Netzsignalisierung mehr- 
fach zwischen den Protokollen SIP, SIP_T, BICC CS2 / ISUP+, 
SS7 (ISUP) umgesetzt wird. Dabei wird vom Controller MGC3 
eine Umsetzung zwischen dem Protokoll BICC CS2 / ISUP+ und 
35 dem erf indungsgemSB zumindest ein Protokollelement - insbe- 
sondere Parameter action - zur Anzeige der Ursache von Modi- 
fikationen des Bearers TDM, RTP/RTCP umfassenden SIP T Proto- 
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koll bewirkt. 



Dazu wird in ausgewahlten SIP_T Nachrichten im Message Body 
neben ein ISUP MIME Content eine SDP Session Qbertragen (mi- 
xed content; siehe RFC204 6 "Multipurpose Internet Mail Exten- 
sions (MIME) Part Two: Media Types", und RFC3204 "MIME media 
types for ISUP and QSIG Objects"), in deren SDP Body ein 
"Content-Disposition" Header Field gemaa RFC2183 eingebettet 
ist, das jeweils zumindest ein erfindungsgemaUes Protokoll- 
element zur Obermittlung der Ursache (n) einer Bearer Modif i- 
kation umfasst, Der "disposition-type" dieses Header Field 
wird auf "session" gesetzt. Zudem wird als neues Protokoll- 
element ein neuer "disposition-parameter" namens "action" zur 
Angabe der Ursache der Bearer Modifikation eingeftihrt und in 
das "Content-Disposition" Header Field eingebettet. 

zur Kombination mehrerer Ursachen/Features k^nnen mehrere 
"action" parameter in einem "Content-Disposition" Header 
Field Obertragen werden. In Anlehnung an die ITU^T Standard 
Q.765.5 (Signalling System No. 7 - Application transport 
mechanism for Bearer Independent Call Control) , welcher gemafi 
dem ITU-T Standard Q. 1902.x BICC CS2 (bearer independent call 
control - capability set 2) z.B. zwischen Call Controllern 
MGC zum Einsatz kommt, umfasst der Wertebereich des "action" 
parameters folgende Werte: connect-backward, connect-forward, 
connect-forward-no-notification, connect-forward-plus- 
notification, connect-forward-no notification-plus-selected 
codec, connect forward-plus-notification-plus-selected codec 
connected, switched, selected-codec, modify-codec, success- ' 
ful-codec-modification, codec-modification-failure, mid-call- 
codec-negotiation, modify-to-selected-codec-information, mid- 
call-codec-negotiation-failure, redirect-backwards-request 
redirect-forwards-request, redirect-bearer-release-request 
redirect-bearer-release-proceed, redirect-bearer-release- ' 
complete, redirect-cut-through-request, redirect-bearer- 
connected-indication, redirect-failure, remote-hold, remote- 
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hold-ack^ remote-retrieval^ remote-ret rieval-ack. 

Ein beispielhaftes erf indungsgemalies "Content-Disposition" 
Header Field sieht sieht in diesem Beispiel wie folgt aus 
5 (das erfindungsgemafie Protokollelement ist durch Fettdruck 
hervorgehoben) : 



10 



Content-Disposition : session 

; actionssremote-retrieval 
; action=sredirect:-forwarda-reqaest 



Wegen der Erfindung ergibt sich der sch^ne Vorteil^ dass die 
BICC CS2 / ISUP+ Informationselemente "Action Indicator" und 
"Bearer Redirection Indicators" sehr einfach mit aussagekraf- 
15 tigen Werten befullt werden k5nnen. 

Als weiteres AusfUhrungsbeispiel der Erfindung wird ein Bea- 
rer Modifikation zwischen drei Teilnehraern A, B, C, die alle 
als SIP Clients SC ausgebildet sein, beschrieben. Der Ablauf 
20 dieses Szenarios ist in Figur 2 dargestellt. Zum vereinfach- 
ten Verstandnis der Erfindung sind in Figur 2 nur SIP Clients 
SC dargestellt und SIP Proxy Server SP weggelassen. 

Bei diesem Beispiel wird zunachst eine Verbindung/Call zwi- 
25 schen den SIP Clients A und B aufgebaut ~ Nachrichten (1)- 
(4) . Anschliefiend legt der SIP Client B den Call auf Hold - 
Nachrichten (5) -(7) - und ruft dann den SIP Client C an - 
Nachrichten (8) -(11). Nach diesem Anruf schickt der SIP 
Client B eine "Re-INVITE" Nachricht (12) zum SIP Client A, 
30 mit der er gleichzeitig das Call Hold aufhebt (Call Retrieve) 
und den von dem SIP Client A ausgehenden Call Stream auf den 
SIP Client C (Bearer Redirect) umlenkt - Nachrichten (12)- 
(14) . SchlieBlich schickt der SIP Client B eine "Re-INVITE" 
Nachricht (15) zum SIP Client C, mit der er den von dem SIP 
35 Client C ausgehenden Call Stream auf SIP Client A (Bearer 

Redirect) umgelenkt wird. Das Endergebnis ist ein Call Trans- 
fer vom SIP Client B zum SIP Client C. Der SIP Client A kann 
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nun mit dem Sip Client C sprechen. 



Nachfolgend werden die Nachrichten (1)-(17) dargestellt, 
wobei in diesen auf die Darstellung von "Via" Header Fields 
verzichtet wird, weil diese ftir den SDP Body Content der SIP 
Nachrichten transparent sind. Dabei wird eine SDP Session in 
einer SIP Message als MIME Message Body gemSB RFC2045 trans- 
portiert. Im Falle von SDP wird in diesem Beispiel der Con- 
tent des SIP Message Body mit folgenden SIP Header Fields 
spezifiziert: 

- "MIME-Version": 

fest auf "MIME-Version: 1.0" gesetzt (= RFC2045) - kann 
optional auch weggelassen werden. 

- "Content-Length" : 

spezifiziert die LSnge des gesamten Message Body. 

- "Content-Type": 

^SS^M^i^'^^o^w?^'' Contents in Form eines Media Type 

S^gSndiLfS^S^^;:^" "^''^ ^^^^^ ^^^^^ 

media type = ""application" 
media subtype = ^^SBF' 
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Eine beispielhafte Nachricht SIP:Re-INVITE mit SDP sieht 
demnach wie folgt aus: 



10 



15 



20 



IMVITB sip: "E.164(B-Tln)"e"IP-Addr(B-Tln)";user=phone 
SIP/2.0 

From: <sip: "E. 164 (A-Tln) "0''IP-Addr (A-Tln) " ; user=phone> 
To: <sip: "E. 164 (B-Tln) "@"IP-Addr (B-Tln) " ; user=phone> 
Call-ID: a84b4c76e66710 
CSeq: 8348 INVITE 

Contact : <sip: "E . 164 (A-Tln) "e-IP-Addr (A-Tln) user=phone> 

MZMB-Verslon : 1.0 
Con1:en1:-Type: application/ SDP 
Content-Length : 166 

v=0 

o=hiQ9200 2890844526 2890844527 IN IP4 "IP-Addr (A-Tln) " 
s= 

c=IN IP4 aaa.bb.cc.dd 
t=0 0 

m=audio 2673 RTP/AVP 4 
a=rtpmap:4 G723/8000 
a=sendrecv 



35 



25 Zur Obertragung der Ursache einer Bearer Modiflkation wird 

far SDP beispielsweise das "Content-Disposition" Header Field 
gemSfl RFC2183 eingesetzt, dessen Syntax derjenigen des vorhe- 
rigen Ausftihrungsbeispiels entsprechen kann. 

30 Eine beispielhaf tes "Content-Disposition" Header Field, das 
wegen einer Bearer Redirection gesendet wird, sieht demnach 
in obiger Nachricht SIP:Re-INVITE, eingebettet in ein SDP 
Protokoll, wie folgt aus (das erf indungsgemafte Protokollele- 
ment ist durch Fettdruck hervorgehoben) : 



[MIME-Version: 1.0] 
Content-Type: application/SDP 
Content-Disposition: session 

; actionsredLLreot-forwasds-reqaest 

40 I Content-Length: xxx 



Ftir das Ausf Uhrungsbeispiel ergeben sich demnach folgende 
Nachrichten (1)-(17), wobei die erfindungsgemSBen Protokoll- 
elemente in den Nachrichten (5), (6), (12), (13), (15) und 
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(16) entsprechend hervorgehoben sind: 

Wachricht (1) : IWVITE Client A -> Client B 

INVITE siprClientBegmx.com SIP/2.0 
5 From: sip:ClientA@munichnet.coin;tag=lc24841 
To: sip: ClientB@ginx.com 
Call-ID: call-973574144@munichnet.com 
CSeq: 1 INVITE 

Contact : <sip: ClientAepc43 .munichnet . com> 
10 Content -Type: appli cation/ sdp 
Content-Length: 161 

v=0 

o»ClientA 2890844526 2890844526 IN IP4 pc43.munichnet.com 

15 8= 

c=IN IP4 192.0.2.101 

t=0 0 

m=audio 49172 RTP/AVP 8 4 
a=rtpmap:8 PCMA/8000 
20 a=rtpmap:4 G723/8000 

Nachricht (2) : 180 Ringing Client B -> Cl ient: A 

SIP/2.0 180 Ringing " 

From: sip:ClientA@munichnet.com;tag=lc24841 
25 To: sip:ClientBegmx.com;tag=0da40dd4-81553525 
Call-ID: call-973574144@munichnet.com 
CSeq: 1 INVITE 

Contact : <sip : ClientBesv71 . gmx . com> 
Content-Length: 0 

30 ' 

Nachriclit (3) ; 200 OK Client B Clie nt A 

SIP/2.0 200 OK ~ 

From: sip: ClientAfimunichnet . com; tag=lc2484 1 
To : sip : ClientBSgmx . com; tag=0da4 0dd4 -81553525 
Call-ID: call-973574144emunichnet.com 
CSeq: 1 INVITE 

Contact: <sip:ClientBesv71.gmx.com> 
Content-Type: application/sdp 
Content -Length: 124 

40 

v=0 

o=ClientB 4770 4770 IN IP4 sv71.gmx.com 

s= 

c=IN IP4 178.224.67.133 
45 t=0 0 

m=audio 3456 RTP/AVP 8 
a=rtpmap:8 PCMO/8000 



35 
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Nachricht (4) ; ACK Client A -> Client B 

ACK sip:ClientB@sv71.ginx.coni SIP/2.0 
From: sip:ClientA@munichnet .cora;tag=lc24841 
To: sip:ClientB@ginx.com;tag=0da40dd4-81553525 
5 Call-ID: call-973574144Smunichnet.com 
CSeq: 1 ACK 
Content -Length : 0 

Nachricht (5) : Re -INVITE Client B -> Client A 

10 INVITE sip: ClientA@pc43.munichnet.com SIP/2.0 

From: sip : ClientB@gmx . com; tag=0da4 0dd4 -8 1553525 

To : sip : ClientA@munichnet . com; tag=lc24 841 

Call-ID: call-973574144@munichnet.com 

CSeq: 2 INVITE 
15 Contact : <sip : ClientBesv71 . gmx . com> 

Content-Type: application/sdp 

Content-Disposition : session ; 
action— reniote-hold 

Content-Length : 128 

20 

v«0 

o=ClientB 4770 4771 IN IP4 sv71.gmx.com 

s== 

c=IN IP4 0. 0.0,0 
25 t=0 0 

a=sendonly 

m=audio 3456 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 

30 Nachricht (6) : 200 OK Client A -> Client B 

SIP/2.0 200 OK 

From: sip:ClientBegxtix, com;tag==0da40dd4-81553525 

To : sip : ClientA@munichnet . com; tag=lc24841 

Call-ID: call-973574144@munichnet.com 
35 CSeq: 2 INVITE 

Contact : <sip : ClientA@pc4 3 .munichnet . com> 

Content -Type : application/sdp 

Content-Disposition : session ; 

actionszremote-hold-ack 
40 Content-Length: 155 

v=0 

o=ClientA 2890844526 2890844527 IN IP4 pc43.munichnet.com 

s= 

45 c=IN IP4 0.0.0.0 
t=0 0 

a=recvonly 

m=audio 49172 RTP/AVP 8 
a=rtpmap:8 PCMA/8000 

50 
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NachricAt: (7) Adc ri .Aenl: B ~> ciA^n*- n 
ACK sxp:Client:Aepc43.iiiunichnet-coni SIP/2. 0 
tS?"*! i S t?T ClientBegmx . com; t ag=0da4 0dd4 -8 1553525 
To. sip ; ClientAQmunichnet . com; tag=lc24841 

Content-Length: 0 

"^^^f!""^^ • Client B -> Client C 

INVITE 3ip; Clientcet omnet.de SIP/2.0 

Call-ID: call-6789egmx.com 
CSeq: 10 INVITE 

con^f '..^^^P • ClientBesvTl . gmx . com> 
Content-Type: application /sdp 
Content -Length: 122 

v=0 

o=ClientB 5612 5612 IN IP4 sv71.gmx.com 

c=IN IP4 178.224.67.133 

t=0 0 

m=audio 3460 RTP/AVP 8 
a=rtpmap:8 PCMU/SOOO 

Call-ID: call-6789@gmx.com 
CSeq: 10 INVITE 

SSteS:LinJ?A?%'""^^®'^^^^-^°^-^-^-> 

?o°'"sio-?i?in??«?®^:*=°™'**^^^0^^40dd4-81^ 
rti 1 Tn f?^^®^''"*"®*'-'^*®' tag-6545b243a 
Call-ID: call-6789@gmx.com 
CSeq: 10 INVITE 

Contact :<sip: ClientC@nb23 . tomnet . de> 
Content-Type: application/sdp 
Content-Length: 127 

v=0 

o=ClientC 293845 293845 IN IP4 nb23.tomnet.de 

c=IN IP4 27.159.111.76 

t=0 0. . 

ni=audio 8275 RTP/AVP 8 " 
a=rtpmap:8 PCMU/8000 
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Nachricht (11) : ACK Client B Client C 

ACK sip: ClientC@toninet.de SIP/2 •O 
From: sip:ClientB@gmx.com; tag=0da40dd4-81553526 
To : sip : CI ientCQ t omnet • de ; tag=654 5b24 3a 
5 Call-ID: call-6789egpmx.com 
CSeq: 10 ACK 
Content-Length: 0 

Nachricht (12) ; Re-INVTTE Client B -> Client A 
10 INVITE sip: ClientAepc43.munichnet.com SIP/2.0 

From: sip: ClientB@gmx. com; tag=0da40dd4-81553525 

To : sip : Client A@munichnet . com; tag=lc2 48 4 1 

Call~ID: call-973574144emunichnet.com 

CSeq: 3 INVITE 
15 Contact : <sip : ClientBe sv7 1 . gmx . com> 

Content-type : application/sdp 

Content-Disposition : session ; 

action»remote-retrieval ; 
action=redirect--£orwards -request 
20 Content-Length: 134 

v=0 

o=ClientB 4770 4772 IN IP4 sv71.gmx.com 

s=^ 

25 c=IN IP4 27.159.111.76 

t=0 0 

a=sendrecv 

m=audio 8275 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 

30 

Nachricht (13) : 200 OK Client A -> Client B 

SIP/2.0 200 OK 

From: sip:ClientB@gmx.com;tag=0da40dd4-81553525 
To : sip : ClientAemunichnet . com; tag=lc24 8 41 
35 Call-ID: call-973574144emunichnet.com 
CSeq: 3 INVITE 

Contact : <sip: ClientAepc43 .munichnet . com> 
Content-Type : application/sdp 
Content-Disposition : session ; 
4 0 action=remo te-retrievaX-ack ; 

action'sredirect-beaurer-connected-indication 
Content-Length : 172 

v=0 

45 o=ClientA 2890844526 2890844528 IN IP4 pc43.munichnet.com 
s= 

c=IN IP4 192.0.2.101 

t=0 0 

a=*sendrecv 
50 m=audio 4 9172 RTP/AVP 8 
a=rtpmap:8 PCMA/8000 
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Maushrxoht: (14) ; ACK Client: B -> Client A 

ACK sip: ClientA@pc43.munichnet.com SIP/2.0 
From: sip:ClientB8gmx.com;tag=0da40dd4-81553525 
To: sip:ClientA@munichnet . com; tag=lc24841 
5 Call-ID: call-9735741440munichnet.com 
CSeq: 3 ACK 
Content-Length: 0 



Haehricht (IS) ; Re-INVITE Client B -> Client C 

10 INVITE Sip: Clientcenb23.tomnet.de SIP/2.0 

From: sip:ClientB8gmx.com;tag=0da40dd4-81553526 

To: sip: ClientC@tomnet.de 

Call-ID: call-6789egmx.com 

CSeq: 11 INVITE 
15 Contact: <sip:ClientB@sv71.gmx.com> 

Content-Type: application/sdp 

Content-Disposition : session ; 

aotionsredirect-£oxwaxds-xeqaest 

Content-Length: 120 

20 

v=0 

o=ClientB 5612 5613 IN IP4 sv71.gmx.com 

s= 

c=IN IP4 192.0.2.101 
25 t=0 0 

m=audio 49172 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 

Nachrioht (16) : 200 OK Client C -> Cli ent B 

SIP/2.0 200 OK 

From: sip: ClientB@gmx. com; tag=0da40dd4-81553526 
To : sip : Clientcetomnet . de ; t ag= 6545b24 3a 
Call-ID: call-6789egmx.com 
CSeq: 11 INVITE 

Contact : <sip : ClientC@nb23 . tomnet . de> 
Content-Type: application/sdp 
Content-Disposition: session; 

action«=redireat-bea3;er-eonneeted-indiccition 

Content-Length: 127 

v=0 

o=ClientC 293845 293846 IN IP4 nb23.tomnet.de 

s= 

c=IN IP4 27.159.111.76 

t=0 0 

m=audio 8275 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 



30 



35 



40 



45 
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Machricht (17) ; ACK Client B -> Client; C 

ACK sip: ClientC@nb23.tomnet.de SIP/2.0 

From: sip:ClientBeginx. com;tag=0da40dd4-81553526 

To : sip : ClientC@tomnet . de ; tag=654 5b243a 

Call-ID: call-6789egmx. com 

CSeq: 11 ACK 

Content-Length : 0 

Dem Fachmann ist klar^ dass die Erfindung selbstverstandlich 
nicht nur in den beschriebenen Szenarien, sondern universell 
in alien Szenarien eingesetzt werden kann^ in denen das SIP 
Oder SIP_T Protokoll verwendet wird. Insbesondere ist ein 
Einsatz in folgenden Szenarien denkbar: 

- VoIP Trunking Siibscriber <-> VoIP Trunking Subscriber mit 
dem Protokoll SIP__T zur Signalisierung zwischen Control- 
lern MGC 

- SIP Client <-> VoIP Trunking Subscriber 

- SIP Client <-> Access Gateway 

- SIP Client <-> H.323 Subscriber 

- SIP Client <-> VoDSL Subscriber (angeschlossen Uber ein 
Integrated Access Device IAD bzw. ein Customer Premises 
Gateway CPG) 

- SIP Client <-> SIP Client 

Abschliefiend sei darauf hingewiesen, dass die Beschreibung 
der fttr die Erfindung relevant en Komponenten des Kommunikati 
onsnetzes grundsStzlich nicht einschrankend zu verstehen ist 
Far einen einschlcLgigen Fachmann ist insbesondere offensicht 
lich, dass Begriffe wie Applikation, Client^ Server, Gateway 
Controller, etc funktional und nicht physikalisch zu ver- 
stehen sind. Somit k5nnen beispielsweise die Endpunkte A, B 
auch teilweise oder vollstandig in Software / Computerpro- 
grammprodukten P und/oder uber mehrere physikalische Einrich 
tungen verteilt realisiert werden. 
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Patentansprtiche 



1. SIP Protokoll, 

umfassend zumindest ein Protokollelement zur Anzeige der 
Ursache(n) einer Bearer Modif ikation. 

2. SIP Protokoll nach Anspruch 1, 

bei dem das Protokollelement in ein Content-Disposition Hea- 
der Field gemMB dem Standard RFC2183 eingebettet ist. 

3. SIP Protokoll nach einem der vorstehenden Ansprflche, 
bei dem das Protokollelement in ein SDP Protokoll nach dem 
Standard RFC2327 eingebettet ist. 

4. SIP Protokoll nach einem der vorstehenden Anspruche, 

bei dem das Protokollelement als Parameter (action) ausgebil- 
det ist, der mehrfach vorgesehen sein kann. 

5. SIP Protokoll nach dem vorstehenden Anspruch, 

bei dem der Wertebereich des Parameters zumindest eihen der 
folgenden Werte aufweist: connect-backward, connect-forward, 
connect-forward-no-notification, connect-forward-plus- 
notification, connect-forward-no notification-plus -selected 
codec, connect forward-plus-notification-plus-selected codec, 
connected, switched, selected-codec, modify-codec, success- 
ful-codec-modification, codec-modification-failure, mid-call- 
codec-negotiation, modify-to-selected-codec-information, mid- 
call-codec-negotiation-failure, redirect-backwards-request, 
redirect-forwards-request, redirect-bearer-release-request, 
redirect-bearer-release-proceed, redirect-bearer-release- 
complete, redirect-cut-through-request, redirect-bearer- 
connected-indication, redirect-failure, remote-hold, remote- 
hold-ack, remote-retrieval, remote-retrieval-ack. 
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6. SIP Protokoll nach einem der vorstehenden Anspriicher 
bei dem das SIP Protokoll nach einem der Standards RFC2543, 
RFC3261 Oder RFC3372 ausgebildet ist. 

5 7. Verfahren zu Modifikation eines Bearers in einem Kommuni- 
kationsnetz, bei dem die Ursache der Bearer Modifikation mit 
einem Protokoll nach einem der vorstehenden ProtokollansprQ- 
che signalisiert wird - insbesondere mit Protokollelementen, 
die im gemafi dem Standard RFC2045 ausgebildeten MIME Message 
10 Body von SIP Messages vorgesehen sind. 

8. Computerprogrammprodukt (P) - insbesondere SIP Client 
Software (SC) umfassend Sof twarecodeabschnitte, mit denen 
ein Verfahren nach dem vorstehenden Verfahrensanspruch durch 

15 zumindest einen Prozessor ausgeftihrt wird. 

9. Vorrichtung - insbesondere Controller (MGC) , SIP Telephon 
Oder SIP Proxy (SP) umfassend Mittel zur DurchfUhrung 
eines Verfahrens nach dem vorstehenden Verfahrensanspruch. 

20 

10. Anordnung - insbesondere paketorientiertes Netz (IN) ^ 
integriertes Sprach-Daten-Netz (SDN) oder hybrides Netz (IN, 
PSTN) umfassend Computerprogrammprodukt e und/oder Vorrich- 
tungen zur Durchftihrung eines Verfahrens nach dem vorstehen- 

25 den Verfahrensanspruch. 



• 
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Zusammenfassung ' <00j 



SIP Protokoll zur Modifikation von Bearerverbindungen 



Ein SIP Protokoll wird um zumindest ein Protokolleleiuent zur 
Anzeige der Ursache(n) einer Bearer Modifkation erweitert. 
Als Folge kann eine deduktive Regenerxerung der Orsache (n) 
anhand der (ibermittelten Bearer Modifikation entf alien. 
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Figur 1 
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